Oops. Thanks for the catch on the title @Archisman-Mridha...! embarrassed

@itowlson Thanks for the quick and in-detail response! Sorry for misunderstanding the issue. I am working on it....

Steps I took to clear out my concepts

• I read about the WASM Component Model and understood what are WASM components.

• Then I read what is and why Spin ?

• Then I read about the architecture of a Spin application and understood what we mean by components in a Spin application.

• I investigated the template at templates/static-fileserver/content and also the Spin application manifest reference.

My current understanding

A spin application contains multiple WASM components. These WASM components can also be located in a remote fileserver. When we execute spin up, these WASM components are download to the local machine.

Components downloading is done by the verified_download function located at - crates/loader/src/http.rs. I just need to put a sloth guard inside verified_download.

Am I right ?

Your understanding is right. Your proposal is almost right, but there is a small nuance: we might now want to place the sloth guard inside verified_download, because then an app with more than one remote component would print the warning several times. This might be okay with clear messaging about which components are taking time; but more usually we place the guard around the entire process (of loading, downloading, etc.), so that it is printed only once. (Again, see the sloth guard around loading Wasm modules, where we print a single "loading is taking a while" rather than listing each component.)

Why do it this way? Consider a manifest with a large number of remote components. (For example, redirect is a remote component. A site might have a lot of redirects.) Printing a message for each of them would produce a lot of console spew for the user to burrow through. Worse, if each component takes, say, 1.1 seconds to load, but in total they take 11 seconds to load, we don't see the feedback at all!

So a more desirable plan is to find where all the remote components are being downloaded (e.g. in a loop or as a map of futures), which will be a place that directly or indirectly calls verified_download. Then the sloth guard can be placed around that loop or those futures or that function or whatever.

Does that help? Again, happy to discuss further or give you more specific pointers if that would be useful.

@itowlson Thanks for being supportive!

I figured it this is where all the components are loaded concurrently : crates/loader/src/local.rs, line number 97 - 103 :

// Load all components concurrently
let components = try_join_all(components.into_iter().map(|(id, c)| async move {
    self.load_component(&id, c)
        .await
        .with_context(|| format!("Failed to load component `{id}`"))
}))
.await?;

I need to put the sloth guard somewhere here. Am I right ?

PS: You can assign me to the issue. I didn't notice any fork made by the person who is currently assigned.

Yes, that looks right. Call warn_if_slothful immediately before that statement, and drop the returned guard immediately after (or, since there is nothing potentially slow after the statement, you can skip the drop - Rust will drop it automatically when it goes out of scope). Thanks!

Good morning :). I pushed a commit. Please let me know if the changes look okay or not.

Oh! Could you mark the PR ready for review please @Archisman-Mridha? It's still draft and can't be merged in that state.

Oh! Could you mark the PR ready for review please @Archisman-Mridha? It's still draft and can't be merged in that state.

Done